Enriching a primary health care version of ICD-10 using SNOMED CT mapping

<p>Abstract</p> <p>Background</p> <p>In order to satisfy different needs, medical terminology systems must have richer structures. This study examines whether a Swedish primary health care version of the mono-hierarchical ICD-10 (KSH97-P) may obtain a richer structure using category and chapter mappings from KSH97-P to SNOMED CT and SNOMED CT's structure. Manually-built mappings from KSH97-P's categories and chapters to SNOMED CT's concepts are used as a starting point.</p> <p>Results</p> <p>The mappings are manually evaluated using computer-produced information and a small number of mappings are updated. A new and poly-hierarchical chapter division of KSH97-P's categories has been created using the category and chapter mappings and SNOMED CT's generic structure. In the new chapter division, most categories are included in their original chapters. A considerable number of concepts are included in other chapters than their original chapters. Most of these inclusions can be explained by ICD-10's design. KSH97-P's categories are also extended with attributes using the category mappings and SNOMED CT's defining attribute relationships. About three-fourths of all concepts receive an attribute of type <it>Finding site </it>and about half of all concepts receive an attribute of type <it>Associated morphology</it>. Other types of attributes are less common.</p> <p>Conclusions</p> <p>It is possible to use mappings from KSH97-P to SNOMED CT and SNOMED CT's structure to enrich KSH97-P's mono-hierarchical structure with a poly-hierarchical chapter division and attributes of type <it>Finding site </it>and <it>Associated morphology</it>. The final mappings are available as additional files for this paper.</p

Approaches to learning openEHR : a qualitative survey, observations, and suggestions

Approaches such as ISO 13606 and openEHR aim to address data reusability by defining clinical data structures called archetypes and templates, based on a reference model. A problem with these approaches is that parts of them currently are rather difficult to learn. It can be hard to imagine what an archetype-based clinical system combined with modern terminology systems will look like and what consequences different modeling choices have, without seeing and experimenting with an operational system. This paper reports findings from a survey among openEHR learners and educators combined with observations of related openEHR mailing list discussions. The paper ends with an opinion piece, where we discuss potentially fruitful ways to learn, explore, and extend archetype-based EHR systems using visualization and examples.The findings highlight potential stumble blocks and solutions and should be of interest for both educators and self-learners

Approaches to learning openEHR : a qualitative survey, observations, and suggestions

Approaches such as ISO 13606 and openEHR aim to address data reusability by defining clinical data structures called archetypes and templates, based on a reference model. A problem with these approaches is that parts of them currently are rather difficult to learn. It can be hard to imagine what an archetype-based clinical system combined with modern terminology systems will look like and what consequences different modeling choices have, without seeing and experimenting with an operational system. This paper reports findings from a survey among openEHR learners and educators combined with observations of related openEHR mailing list discussions. The paper ends with an opinion piece, where we discuss potentially fruitful ways to learn, explore, and extend archetype-based EHR systems using visualization and examples.The findings highlight potential stumble blocks and solutions and should be of interest for both educators and self-learners

Applying representational state transfer (REST) architecture to archetype-based electronic health record systems

Background The openEHR project and the closely related ISO 13606 standard have defined structures supporting the content of Electronic Health Records (EHRs). However, there is not yet any finalized openEHR specification of a service interface to aid application developers in creating, accessing, and storing the EHR content. The aim of this paper is to explore how the Representational State Transfer (REST) architectural style can be used as a basis for a platform-independent, HTTP-based openEHR service interface. Associated benefits and tradeoffs of such a design are also explored. Results The main contribution is the formalization of the openEHR storage, retrieval, and version-handling semantics and related services into an implementable HTTP-based service interface. The modular design makes it possible to prototype, test, replicate, distribute, cache, and load-balance the system using ordinary web technology. Other contributions are approaches to query and retrieval of the EHR content that takes caching, logging, and distribution into account. Triggering on EHR change events is also explored. A final contribution is an open source openEHR implementation using the above-mentioned approaches to create LiU EEE, an educational EHR environment intended to help newcomers and developers experiment with and learn about the archetype-based EHR approach and enable rapid prototyping. Conclusions Using REST addressed many architectural concerns in a successful way, but an additional messaging component was needed to address some architectural aspects. Many of our approaches are likely of value to other archetype-based EHR implementations and may contribute to associated service model specifications

Applying representational state transfer (REST) architecture to archetype-based electronic health record systems

Background The openEHR project and the closely related ISO 13606 standard have defined structures supporting the content of Electronic Health Records (EHRs). However, there is not yet any finalized openEHR specification of a service interface to aid application developers in creating, accessing, and storing the EHR content. The aim of this paper is to explore how the Representational State Transfer (REST) architectural style can be used as a basis for a platform-independent, HTTP-based openEHR service interface. Associated benefits and tradeoffs of such a design are also explored. Results The main contribution is the formalization of the openEHR storage, retrieval, and version-handling semantics and related services into an implementable HTTP-based service interface. The modular design makes it possible to prototype, test, replicate, distribute, cache, and load-balance the system using ordinary web technology. Other contributions are approaches to query and retrieval of the EHR content that takes caching, logging, and distribution into account. Triggering on EHR change events is also explored. A final contribution is an open source openEHR implementation using the above-mentioned approaches to create LiU EEE, an educational EHR environment intended to help newcomers and developers experiment with and learn about the archetype-based EHR approach and enable rapid prototyping. Conclusions Using REST addressed many architectural concerns in a successful way, but an additional messaging component was needed to address some architectural aspects. Many of our approaches are likely of value to other archetype-based EHR implementations and may contribute to associated service model specifications